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Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 

Official Protocol Standards" (STD 1) for the standardization state 

and status of this protocol. Distribution of this memo is unlimited. 
Abstract 


This document defines an XML format for the representation of civic 


location. This format is designed for use with Presence Information 
Data Format Location Object (PIDF-LO) documents and replaces the 
civic location format in RFC 4119. The format is based on the civic 


address definition in PIDF-LO, but adds several new elements based on 
the civic types defined for Dynamic Host Configuration Protocol 
(DHCP), and adds a hierarchy to address complex road identity 
schemes. The format also includes support for the xml:lang language 
tag and restricts the types of elements where appropriate. 
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Introduction 


Since the publication of the original PIDF-LO civic specification, in 
[RFC4119], it has been found that the specification is lacking a 
number of additional parameters that can be used to more precisely 
specify a civic location. These additional parameters have been 
largely captured in [RFC4776]. 


This document revises the GEOPRIV civic form to include the 
additional civic parameters captured in [RFC4776]. The document also 
introduces a hierarchical structure for thoroughfare (road) 
identification, which is employed in some countries. New elements 
are defined to allow for even more precision in specifying a civic 
location. 


Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


The term "thoroughfare" is used in this document to describe a road 
or part of a road or other access route along which a final point is 
identified. This is consistent with the definition used in 
[UPU-S42]. 


Changes from PIDF-LO 
1. Additional Civic Address Types 


[RFC4776] provides a full set of parameters that may be used to 
describe a civic location. Specifically, [RFC4776] lists several 
civic address types (CAtypes) that require support in the formal 
PIDF-LO definition that are not in [RFC4119]. 


These changes include new elements that are required to support more 
complex structures for naming street addresses. This is described in 
more detail in Section 3.2. 
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t----------- +-------- ag cscs cca e A A + 
| New Field | CAtype | Description | Example 
t----------- +-------- toa - 55 = t-------------- + 
| BLD | 25 | Building (structure) | Hope Theatre 

| | | | 

| UNIT | 26 | Unit (apartment, suite) | 12a 

| | | | 

| ROOM | 28 | Room | 450F 

| PLC | 29 | Place-type | office 

| | | | 

| PCN | 30 | Postal community name | Leonia 

| | | | 

| POBOX | 31 | Post office box (P.O. box) | u40 

| | | | 

| ADDCODE | 32 | Additional Code | 13203000003 

| SEAT | 33 | Seat (desk, cubicle, | WS 181 

| | | workstation) | 

| | | | 

| RD | 34 | Primary road or street | Broadway 

| RDSEC | 35 | Road section | 14 

| | | | 

| RDBR | 36 | Road branch | Lane 7 

| | | | 

| RDSUBBR | 37 | Road sub-branch | Alley 8 

| PRM | 38 | Road pre-modifier | Old 

| | | | 

| POM | 39 | Road post-modifier | Extended 
+----------- +-------- A erir a 5 = t-------------- + 


Table 1: New Civic PIDF-LO Types 
A complete description of these types is included in [RFC4776]. 


New Thoroughfare Elements 


In some countries, a thoroughfare can be broken up into sections, and 


it is not uncommon for street numbers to be repeated between 
sections. A road section identifier is required to ensure that an 
address is unique. For example, "West Alice Parade" in the figure 
below has 5 sections, each numbered from 1; unless the section is 
specified, "7 West Alice Parade" could exist in 5 different places. 
The "RDSEC" element is used to specify the section. 
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Minor streets can share the same name, so that they can only be 
distinguished by the major thoroughfare with which they intersect. 
For example, both "West Alice Parade, Section 3" and "Bob Street" 
could both be intersected by a "Carol Lane". The "RDBR" element is 
used to specify a road branch where the name of the branch does not 
uniquely identify the road. Road branches MAY also be used where a 
major thoroughfare is split into sections. 


Similar to the way that a road branch is associated with a road, a 
road sub-branch is associated with a road branch. The "RDSUBBR" 
element is used to identify road sub-branches. 


The "A6" element is retained for use in those countries that require 
this level of detail. Where "A6" was previously used for street 
names in [RFC4119], it MUST NOT be used; the "RD" element MUST be 
used for thoroughfare data. 


The following figure shows a fictional arrangement of roads where 
these new thoroughfare elements are applicable. 


| | 

Carol La. Carol La. | Bob 

| II St; 
| West Alice Pde. | | 
/ / / | | 

Sec.1 Sec.2 Sec.3 | Sec.4 | | Sec.5 

a aa a a Carol i 
Alley 2 | La. | | 
|| 


3.2.1. Street Numbering 


The introduction of new thoroughfare elements affects the 
interpretation of several aspects of more specific civic address 
data. In particular, street numbering (the "HNO" element) applies to 
the most specific road element specified, that is, the first 
specified element from "RDSUBBR", "RDBR", "RDSEC", or "RD". 


3.2.2. Directionals and Other Qualifiers 


The "PRM", "POM", "PRD", "POD", and "STS" elements always apply to 
the value of the "RD" element only. If road branches or sub-branches 
require street suffixes or qualifiers, they MUST be included in the 
"RDBR" or “RDSUBBR" element text. 
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3.3. Country Element 


The "country" element differs from that defined in [RFC4119] in that 
it now restricts the value space of the element to two uppercase 
characters, which correspond to the alpha-2 codes in [ISO.3166-1]. 


3.4. Al Element 


The "Al" element is used for the top-level subdivision within a 
country. In the absence of a country-specific guide on how to use 
the A-series of elements, the second part of the ISO 3166-2 code 
[ISO.3166-2] for a country subdivision SHOULD be used. The ISO 
3166-2 code is formed of a country code and hyphen plus a code of 
one, two, or three characters or numerals. For the "Al" element, the 
leading country code and hyphen are omitted and only the subdivision 
code is included. 


For example, the codes for Canada include CA-BC, CA-ON, CA-QC; 
Luxembourg has just three single-character codes, LU-D, LU-G, and 
LU-L; Australia uses both two- and three-character codes, AU-ACT, 
AU-NSW, AU-NT; and France uses numerical codes for mainland France 
and letters for territories, FR-75, FR-NC. This results in the 
following fragments: 

<country>CA</country><A1>ON</A1> 

<country>LU</count ry><A1>L</A1> 

<count ry>AU</country><A1>ACT</A1> 

<country>FR</count ry><A1>75</Al1> 

3.5. Languages and Scripts 


The XML schema defined for civic addresses allows for the addition of 
the "xml:lang" attribute to all elements except "country" and "PLC", 


which both contain language-neutral values. The range of allowed 
values for "country" is defined in [1S0.3166-1]; the range of allowed 
values for "PLC" is described in the IANA registry defined by 
[RFC4589]. 


The "script" field defined in [RFC4776] is omitted in favor of using 
the "xml:lang" attribute with a script subtag [RFC4646]. 


It is RECOMMENDED that each "civicAddress" element use one language 
only, or a combination of languages that is consistent. Where a 
civic location is represented in multiple languages, multiple 
"CivicAddress" elements SHOULD be included in the PIDF-LO document. 
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For civic addresses that form a complex to describe the same 
location, these SHOULD be inserted into the same tuple. 


3.5.1. Converting from the DHCP Format 


The DHCP format for civic addresses [RFC4776] permits the inclusion 
of an element multiple times with different languages or scripts. 
However, this XML form only permits a single instance of each 
element. Multiple "civicAddress" elements are required if any 
element is duplicated with different languages. If the same language 
and script are used for all elements, or no elements are duplicated, 
the format can be converted into a single civic address. 


Where there are duplicated elements in different languages, a 
"civicAddress" element is created for each language that is present. 
All elements that are in that language are included. Elements that 
are language independent, like the "country" and "PLC" elements, are 
added to all "civicAddress" elements. 


3.5.2. Combining Multiple Elements Based on Language Preferences 


If the receiver of the XML representation is known, and that receiver 
has indicated language preferences, a single XML format can be 
constructed using those preferences. For example, language 
preferences can be indicated by the "Accept-Language" header in the 
SIP or HTTP protocols. 


All elements that have only one value, irrespective of language, are 
used. Where multiple values exist, each value is assigned a 
weighting based on the language preferences. The value with the 
highest weighting is selected. An arbitrary value is selected if two 
values have the same preference, if there is no preference for the 
available languages, or if there are conflicting values with the same 
language. 


3.6. Whitespace 


The XML schema [W3C.REC-xmlschema-2-20041028] defined in Section 4 
uses a base type of "token" instead of "string" as used in [RFC4119]. 
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The "token" type ensures that whitespace within instance documents is 
normalized and collapsed before being passed to a processor. This 
ensures that the following fragments are considered equivalent by XML 
processors: 


<A4>North Wollongong</A4> 


<Al>North 
Wollongong</A1> 


<Al> 
North Wollongong 
</A1> 


Whitespace may still be included in values by using character 
references, such as "&#x20;". 


4. Civic Address Schema 


<?xml version="1.0"?> 

<xs:schema 
targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" 
xmlns:xs="http://www.w3.org/2001/XMLSchema" 
xmilns:ca="urn:ietf:params:xml:ns:pidf:geoprivl0:civicAddr" 
xmlns:xml="http://www.w3.org/XML/1998/namespace" 
elementFormDefault="qualified" attributeFormDefault="unqualified"> 


<xs:import namespace="http://www.w3.org/XML/1998/namespace" 
schemaLocation="http://www.w3.org/2001/xml.xsd"/> 


<xs:simpleType name="iso3166a2"> 
<xs:restriction base="xs:token"> 
<xs:pattern value="[A-Z]{2}"/> 
</xs:restriction> 
</xs:simpleType> 


<xs:complexType name="caType"> 
<xs:simpleContent> 
<xs:extension base="xs:token"> 
<xs:attribute ref="xml:lang" use="optional"/> 
</xs:extension> 
</xs:simpleContent> 
</xs:complexType> 
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<xs:element name="civicAddress" type="ca:civicAddress"/> 
<xs:complexType name="civicAddress"> 
<xs:sequence> 


<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<XS 
<XS 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 


</xs:sequence> 


:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:element 
:any namespace="##other" processContents="lax" 


name="country" type="ca:iso3166a2" minOccurs="0"/> 
name="A1l" type="ca:caType" minOccurs="0"/> 
name="A2" type="ca:caType" minOccurs="0"/> 
name="A3" type="ca:caType" minOccurs="0"/> 
name="A4" type="ca:caType" minOccurs="0"/> 
name="A5" type="ca:caType" minOccurs="0"/> 
name="A6" type="ca:caType" minOccurs="0"/> 
name="PRM" type="ca:caType" minOccurs="0"/> 
name="PRD" type="ca:caType" minOccurs="0"/> 
name="RD" type="ca:caType" minOccurs="0"/> 
name="STS" type="ca:caType" minOccurs="0"/> 
name="POD" type="ca:caType" minOccurs="0"/> 
name="POM" type="ca:caType" minOccurs="0"/> 
name="RDSEC" type="ca:caType" minOccurs="0"/> 
name="RDBR" type="ca:caType" minOccurs="0"/> 
name="RDSUBBR" type="ca:caType" minOccurs="0"/> 
name="HNO" type="ca:caType" minOccurs="0"/> 
name="HNS" type="ca:caType" minOccurs="0"/> 
name="LMK" type="ca:caType" minOccurs="0"/> 
name="LOC" type="ca:caType" minOccurs="0"/> 
name="FLR" type="ca:caType" minOccurs="0"/> 
name="NAM" type="ca:caType" minOccurs="0"/> 
name="PC" type="ca:caType" minOccurs="0"/> 
name="BLD" type="ca:caType" minOccurs="0"/> 
name="UNIT" type="ca:caType" minOccurs="0"/> 
name="ROOM" type="ca:caType" minOccurs="0"/> 
name="SEAT" type="ca:caType" minOccurs="0"/> 
name="PLC" type="xs:token" minOccurs="0"/> 
name="PCN" type="ca:caType" minOccurs="0"/> 
name="POBOX" type="Ca:caType" minOccurs="0"/> 
name="ADDCODE" type="ca:caType" minOccurs="0"/> 


minOccurs="0" maxOccurs="unbounded"/> 


<xs:anyAttribute namespace="##any" processContents="lax"/> 
</xs:complexType> 
</xs:schema> 
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7. 


Example 


<civicAddress xml:lang="en-AU" 
xmlns="urn:ietf:params:xml:ns:pidf:geoprivl0:civicAddr"> 
<country>AU</country> 
<A1>NSW</A1> 
<A3> Wollongong 
</A3><A4>North Wollongong 
</A4> 
<RD>Flinders</RD><STS>Street</STS> 
<RDBR>Campbell Street</RDBR> 
<LMK> 
Gilligan’s Island 
</LMK> <LOC>Corner</LOC> 
<NAM> Video Rental Store </NAM> 


<PC>2500</PC> 

<ROOM> Westerns and Classics </ROOM> 

<PLC>store</PLC> 

<POBOX>Private Box 15</POBOX> 
</civicAddress> 


Security Considerations 


The XML representation described in this document is designed for 
inclusion in a PIDF-LO document. As such, it is subject to the same 
security considerations as are described in [RFC4119]. 
Considerations relating to the inclusion of this representation in 
other XML documents are outside the scope of this document. 


IANA Considerations 


1. URN sub-namespace registration for 
‘urn:ietf:params:xml:ns:pidf:geoprivl0:civicAddr’ 


This document defines a new XML namespace (as per the guidelines in 
[RFC3688]) that has been registered with IANA. 


URI: urn:ietf:params:xml:ns:pidf:geoprivl0:civicAddr 


Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), 
Martin Thomson (martin.thomson@andrew.com) . 
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XML: 
BEGIN 
<?xml version="1.0"?> 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
"http: //www.w3.org/TR/xhtml1/DTID/xhtmli-strict.dtd"> 
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> 
<head> 
<title>GEOPRIV Civic Address</title> 
</head> 
<body> 
<hl>Format for Distributing Civic Address in GEOPRIV</h1> 
<h2>urn:ietf:params:xml:ns:pidf:geoprivl10:civicAddr</h2> 
<p>See <a href="http://www.rfc-editor.org/rfc/rfc5139.txt"> 
RFC5139</a>.</p> 
</body> 
</html> 
END 


7.2. XML Schema Registration 


This section registers an XML schema as per the procedures in 
[RFC3688]. 


URI: urn:ietf:params:xml:schema:pidf:geoprivl0:civicAddr 


Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), 
Martin Thomson (martin.thomson@andrew.com) . 


The XML for this schema can be found as the entirety of Section 4 
of this document. 


7.3. CAtype Registry Update 
This document updates the civic address type registry established by 


[RFC4776]. The "PIDF" column of the CAtypes table has been updated 
to include the types shown in the first column of Table 1. 
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